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Executive Summary 


Problem Definition The Army’s Program Executive Office (PEO) - Soldier has the complex task of ac¬ 
quiring and integrating a system of soldier equipment that meets their mission requirements. In order to 
better assess trade-offs in different soldier architectures, they seek an improved simulation capability that 
better represents the individual soldier on the battlefield. No single model provides this capability. They 
are pursuing a strategy of integrating three different simulation models to take advantage of the strengths of 
each. These models are the Infantry Warrior Simulation (IWARS), One Semi-Automated Forces (OneSAF), 
and the Combined-Arms Analysis Tool for the 21st Century (COMBAT XXI ). In this year, the fifth year 
of their effort, they focused on a series of integration tasks. The most significant of these is the real-time 
dynamic integration of the models that allows them to share data and algorithms during a model run 


Technical Approach The approach to this modeling integration was to break down the overarching inte¬ 
gration task into a series of discrete tasks that could be performed by model development teams involved in 
this project. 

• Enable the models to communicate in real time, sharing data and algorithms using the High Level 
Architecture integration technology. 

• Integrating the ability to model advanced body armor, thermal weapons sights, direct fire weapons, and 
detailed casualty assessment into the candidate models. 

• Integrate the ability to model advanced command and control such as networked call for fire, soldier 
blue force tracking alerts, and soldier radio systems into the candidate models. 

• Enable sharing of a common environmental model using OneSAF's Environmental Runtime Component. 

• Enable sharing of common scenario data via the Military Scenario Definition Language. 

• Enable scenario sharing using approved soldier scenarios from Training and Doctrine Command. 

• Set up processes that enable analysis of PEO Soldier decision items using proper scenarios, doctrine, 
and underlying data. 


Results Much of the focus and effort for this year’s work was centered on developing a working federation 
using High Level Architecture. A decision was made early in the year to use Research, Development, and 
Engineering Command’s (RDECOM) Modeling Architecture for Technology. Research, and Experimentation 
(MATREX) for integration. Their federation architecture was designed to support the Future Combat 
Systems program, so it had the greatest support for advanced communications and command and control 
interactions. Both IWARS and OneSAF had already done development to support the MATREX federation 
object model. Another decision was made early in the year to adopt model driven architectures (MDA) 
to drive simulation development. In this manner, high-level activity diagrams represented the battlefield 
concepts. These were used to assign activities to different simulation models. More detailed sequence 
diagrams showed how the federation handled these activities using the technical details of the run-time 
infrastructure and federation object model. This communication enabled the modeling teams to better 
focus their efforts on code development. It also enabled explanation of these interactions to those who could 
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not read the code. This aids verification and validation of the models, along with analysis. By the end of the 
year, the team had a working test scenario in which OneSAF controlled the vehicles and indirect fire elements, 
while 1WARS controlled the dismounted forces moving into a village for a raid. 1 his architecture supports 
analysis of the impact of soldier equipment, to include weapons, sensors, body armor, and communications 
gear, on the dismounted squad, along with their supporting mounted forces. 

In addition to achieving a running federation, the modeling team achieved progress in the following areas as 
well: 


• Detailed representation of body armor in IWARS, and rough representation in COMBA'I XXI 

• Agreement on data structures and algorithms required to represent casualties using detailed physiological 
models. 

• Representation of call for fire, communications, and command and control within the federation. 

• Use of OneSAF’s environmental runtime component, as a common terrain model. 

• Use of the military scenario definition language as a common scenario representation. 

• Agreement on a scenario for the upcoming year that will test the federation’s analysis capabilities and 
improve the processes for model development and analysis. 

Given the progress made this year in achieving a level of integration next year’s efforts will focus on maturing 
the federation to the point where it is useful for analysis. Key tasks to achieve this include time management 
and automatic federation start stop in order to do batch runs. In addition, scenario data, input data, and 
output data will have to be managed closely. PEO Soldier must, work with Training and Doctrine Command 
to develop approved scenarios and vignettes for analysis. Finally, verification and validation of the federation 
must be addressed. Successful completion of these analysis tasks will deliver PEO Soldier a capability to do 
quick-turn model runs in order to assess the impacts of different soldier architectures oil mission performance. 
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1 BACKGROUND 


1 Background 

The PEO Soldier Simulation Road Map is an effort 
by PEO Soldier to develop within the Army a ca¬ 
pability to model the effects of soldier equipment on 
unit-level effectiveness - focused at platoon and be¬ 
low. This study is the fifth year of collaborative ef¬ 
fort between Program Executive Office Soldier and 
the United States Military Academy (USMA) Oper¬ 
ations Research Center (ORCEN). Previous studies 
have led this effort to where it stands today. During 
the first year, the ORCEN analyzed simulation re¬ 
quirements and recommended a 3-model approach in¬ 
tegrating I WARS, OneSAF, and COMBAT XXI . Dur¬ 
ing the second year, ORCEN effort was focused on es¬ 
tablishing a memorandum of agreement between the 
three modeling agencies and mapping soldier equip¬ 
ment lists into prioritized modeling requirements. In 
the third year of effort, the modeling agencies signed 
the agreements and started prioritizing their work 
into common environmental and scenario represen¬ 
tations that would enable “soft” linkages between the 
models. In the fourth year, these “soft” linkages were 
achieved, allowing scenarios to be run in one model, 
stopped, passed to a second model, and run to com¬ 
pletion. In year, five, as this report details, hard link¬ 
ages were achieved allowing the models to exchange 
data during run-time. 

In November of 2003, Brigadier General James 
Moran, PEO Soldier, commissioned the ORCEN to 
develop a model, or family of models, that would 
support PEO Soldier decision making with respect 
to soldier equipment. The ORCEN, working within 
the PEO, further defined the need as, “PEO Soldier 
needs a simulation that allows the evaluation of pla¬ 
toon effectiveness based upon changes in Soldier tac¬ 
tical mission system (STMS) characteristics.” Ful¬ 
fillment of this need would bring the PEO in line 
with the Army’s Simulation and Modeling for Acqui¬ 
sition, Requirements, and Training (SMART) pro¬ 
gram. The SMART program “involves rapid proto¬ 
typing using M&S [modeling and simulation] media 
to facilitate systems engineering so that materiel sys¬ 
tems meet users’ needs in an affordable and timely 
manner while minimizing risk (Army Modeling and 


Simulation Office, 2002). ” Taking this need, the OR¬ 
CEN evaluated a series of alternatives that ranged 
from creating a brand new simulation to adopting, 
in its entirety, and existing simulation. The team 
concluded that while developing a single model was 
cost and time prohibitive, no single existing model 
met the PEO’s requirements. They recommended a 
federation of models including I WARS. OneSAF, and 
COMBAT XXI . PEO Soldier accepted this recommen¬ 
dation and asked the ORCEN to lead the effort in 
building a team to develop this federation (Tollefson 
and Boylan, 2004). 

While everyone understood the need for a federated 
modeling solution, the composition, type of integra¬ 
tion, and level of detail for the federation w r ere not so 
simple to agree upon. The ORCEN worked two par¬ 
allel efforts from June 2004 until July 2005. First, 
they had to establish memoranda of agreement that 
would enable funding and collaboration within this 
project. This required significant negotiation be¬ 
tween PEO Soldier, the Natick Soldier Center (devel¬ 
oper of I WARS), PEO Simulation Training and In¬ 
strumentation (PEO-STRI - developer of OneSAF), 
and Training and Doctrine Command Analysis Cen¬ 
ter - White Sands Missile Range (TRAC-WSMR - 
developer of COMBAT XXI ). Second, they had to 
further refine the analysis requirements for the fed¬ 
eration. In short, PEO Soldier did not have a list of 
analysis requirements; they had a list of equipment. 
The ORCEN worked with the PEO to categorize and 
streamline this list into a discrete set of modeling re¬ 
quirements that could be implemented by the mem¬ 
bers of the federation. Once these requirements were 
understood, it was easier for the modeling agencies 
to agree to develop these capabilities (Martin, 2005). 

Given an agreement to work together, and a list of 
analysis needs, the next significant question is where 
to start. The modeling teams first came together un¬ 
der the signed agreements in 2005. However, there 
was not general agreement on the integration tech¬ 
nology or on the initial analysis tasks. The OR¬ 
CEN worked with the PEO to select from the list 
of analysis requirements, a very short list of equip¬ 
ment and associated analysis questions. Collectively, 
the group decided to begin effort on “soft” linkages. 
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1 Equivalent terrain representations for 
specific areas of common interest 

2. Equivalent environments, as appropriate 

3. Equivalent methodologies or utilization of 
the preferred methodology from one of the 
simulations, as appropriate 

4. Equivalent algorithms, as appropriate 

5. Equivalent data, as appropriate 

6. Ghosting and or proxies of entities 

7. Time event management 

8. Development of behavior sets 

9. Method to obtain appropriate behavior 
interactions between COMBAT xxl and 

1WARS entities 

10. The best way to keep proxy elements in 
complimentary model updated 

11. Use of simulation specific 
capabilities constructs 

12. Usability of the combined simulation 

13. Data output and analysis 


Tab 1 Model linkage framework. 


In other words, the models in the federation would 
not exchange data during run-time. Instead, they 
would agree on a common terrain representation and 
a common scenario representation. Using these repre¬ 
sentations, different models would take over the sce¬ 
nario. run a portion of the fight, update the status 
of the combatants, then pass that information to an¬ 
other model Under this approach, the team could 
get started more quickly, develop a working relation¬ 
ship, and work out challenges to an eventual “hard” 
linkage where the models exchanged data wdtli each 
other during the run. A brief list of the elements of 
the model linkage framework developed by this effort 
is shown in Table l(Boylan, 2006). 

During May of 2007, in the fourth year of effort for 
this project, the modeling team achieved a “soft'' in¬ 
tegration of two models, 1WARS and COMBAT XXI , 
for a small room-clearing scenario, as shown in Fig¬ 
ure 1. This was made possible by the agreement 
between all of the development teams to use One- 


SAF's Environmental Runtime Component for com¬ 
mon terrain and environment representation. They 
also agreed to use the Military Scenario Definition 
Language (MSDL) to share scenario data. Using this 
integration the ORCEN analyst was able to collect 
mission performance data for the simulation run us¬ 
ing a 2x2 factorial design. In this case, he represented 
two different levels of body armor and night vision 
equipment (Kramlidi, 2007). This proof-of-coneept 
integration was a major step in the five-year history 
of this project. The three models, selected in year 1, 
came together wdtli a common understanding of the 
analysis requirements, established in year 2, and a 
common picture of the integration requirements, es¬ 
tablished in year 3. Most important in this success¬ 
ful linkage w r as the working relationships developed 
by the modeling teams and their commitment to the 
tasks at hand. 

The successful proof-of-concept integration laid the 
groundwork for the 2007-2008 tasks for the Simula¬ 
tion Road Map. This work is the springboard for the 
academic year 2007-2008 tasks, bringing the federa¬ 
tion closer to a federated analysis capability. 

One of the products of last year's study wras develop¬ 
ing a consensus and task list to support work for the 
following year. The task lists in ANNEX A highlight 
those efforts for each component model. 

2 Systems Engineering Process for the 
Development of Federated 
Simulations from Operational 
Requirements 

The success of last year's file-based integration en¬ 
abled the focus of this year’s effort to be on the 
development of a real-time “hard” linkage between 
the models - a federation. Prior to proposing this 
effort, the ORCEN solicited the assistance of the 
Virginia Modeling. Analysis, and Simulation Center 
(VMASC) for their expertise and research in fed¬ 
eration development. Key integration technologies 
such as high-level architecture, the federation de¬ 
velopment process, conceptual interoperability, and 
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2 SYSTEMS ENGINEERING PROCESS FOR 1 HE DEVELOPMENT OF FEDERATED 

SIMULATIONS FROM OPERATIONAL REQUIREMENTS 


Room Cleared 

Exit Building and Transfer to COMBAT^ 1 



Continue in COMBAT XXI 



Fig 1 File-based integration between IWARS and C()MBAT XXI . 


model driven architectures were investigated. 

This section documents the process and summarizes 
some necessary requirements to apply a systems en¬ 
gineering process to align acquisition, development, 
testing, training, and operational support for PEO 
Soldier. 1 lie systems engineering process proposed in 
this section is based on several relevant and commu¬ 
nity accepted methods and standards. 1 hose meth¬ 
ods are reviewed m order to root the proposed process 
in already accepted work. The documented print iples 
should support extending this toother alternatives as 
well 

These ideas generalize well to other systems acquisi¬ 
tion problems. Currently, acquisition, development, 
testing, training, and operational support are only 
loosely coupled. 1 lie approach recommended in this 
report allows the reuse of significant findings, op¬ 
erational requirements, and constraints bridging the 
phases of the systems lifecycle. This results in better 
aligned support for the warfighters needs. 

2.1 Relevant Methods and Standards 

1 lie necessity of applying systems engineering pro¬ 
cesses in support of system decisions in all phases of 


the lifecycle is nothing new. Also, to anchor such 
processes in the operational necessities defined by re¬ 
quirements is common procedure. What is innova¬ 
tive is the idea to use common artifacts in support of 
all phases of the useful lifecycle of systems in a con¬ 
sistent way, covering all aspects of the operational 
lifecycle. This starts with the identification of an op¬ 
erational gap. a certain capability that is required 
to implement doctrine. Once this capability is iden¬ 
tified, the procurement and acquisition community 
has to decide if a new system should be introduced 
to deliver the function implementing the capability, 
or if an existing system can be improved to provide 
the functionality. 

2.1.1 Developing Essential Tasks, Related 
Equipment, and Metrics 

Truly integrated operations depend on a solid foun¬ 
dation of common elements understood between all 
participating partners and organizations. The cur¬ 
rent approach is to establish a mission essential task 
list (MET1 ) that lists the operational tasks forces 
need to perform to doctrinally accomplish a given 
mission. These tasks may also be mapped to a com- 
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moil Universal Joint Task List (UJTL). Several sep¬ 
arately initiated US DoD programs as well as some 
Homeland Security efforts are planning to base their 
metrics of performance on mission essential tasks. 
Within NATO, comparable efforts are undertaken, 
although the resulting task lists are not always well 
aligned between all nations. In all these efforts a mil¬ 
itary task is identified, and necessary capabilities to 
perform this task are captured. The targeted result 
is a list of mission essential tasks, related capabilities, 
and metrics to measure the performance. It should 
be pointed out that mission essential tasks should 
not be tightly coupled with a system or a capability 
implementation. The tasks should describe the con¬ 
ceptual capability which at least in theory can be 
delivered by several systems or system components. 

These ideas are tightly connected with the Military 
Missions and Means Framework (MMF ) (Sheehan 
et ah. 2004). The context is defined by an opera¬ 
tional environment, enemy missions and forces, and 
a friendly military mission. This mission requires 
set of mission essential tasks, other specified or im¬ 
plied tasks, required capabilities, and military means 
in terms of forces and equipment that are needed 
to conduct the mission. The MMF is therefore the 
operational view describing what operational nodes 
are needed and which operational activities are con¬ 
ducted. The systems, which are normally systems 
that have to be evaluated or that are under test, pro¬ 
vide capabilities that implement the means needed to 
conduct a mission. This is consistent with the sys¬ 
tems view of how missions and means are concretely 
instantiated. 

In order to assure scientific evaluations based on ex¬ 
perimentation. metrics are needed that specify what 
data is collected and how this data is used to define 
success or failure. In order to be able to conduct the 
evaluation, these task elements must be put into a 
meaningful operational context. This is done by set¬ 
ting them into the context of a scenario or a vignette. 
The focus of all these activities should be the evalu¬ 
ation of the system. It is also essential to track other 
capabilities and their relative changes based on the 
system to be evaluated, in particular when it comes 
to indirect or higher order effects. Therefore, the de¬ 


sign process for setting up a scenario is as follows: 

1. The essential tasks required to accomplish the 
mission form the initial task list. 

2. A system is identified that provides the required 
capabilities for the mission essential tasks. 

3. All the tasks that are conducted by the system 
in support of the required capabilities are added 
to the task list to be evaluated. 

4. All effects that are influenced (higher order ef¬ 
fects) by the system are also captured. 

5. Operational vignettes or scenarios comprising all 
tasks on the task list (if necessary prioritized bv 
operational effects) are defined. 

6. Metrics are selected that capture the success of 
the mission, the effectiveness of supporting tasks, 
and the related effects achieved. 

The result of these steps is a scenario or a list of 
vignettes that comprises all tasks, effects, and metrics 
needed to evaluate the system. 

2.1.2 NATO Code of Best Practice for C2 
Assessment 

The North Atlantic Treaty Organization (NATO) 
Code of Best Practice for Command and Control 
(C2) Assessment was produced in order to facilitate 
high quality evaluations. It identifies several steps of 
an iterative process: 

• In the initial phase, the team starts with the 
problem formulation and related high-level solution 
strategies. This corresponds with the question of 
what the system to be evaluated should do in sup¬ 
port of which missions. 

• In the second phase, three steps have to lx 1 con¬ 
ducted to refine the ideas of the initial phase. In this 
phase, the team identifies the human and organiza¬ 
tional factors (the concepts to be evaluated, where 
they are, how they operate, etc.) and puts them into 
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the context of a scenario. In addition, the measures 
of merit are decided. This phase deals with identify¬ 
ing the important concepts and processes, their role 
in a scenario, and how to measure success or failure. 

• Only after the conceptualization is done, the im¬ 
plementation phase is conducted. The selection of 
methods and tools such as simulation systems to 
use, or supporting tools for the evaluation - is one 
of the steps. As important as the tool selection is to 
ensure that the necessary data is available or can be 
obtained within the constraints of the project. 

• Finally, risk and uncertainty management, includ¬ 
ing sensitivity analysis of proposed solution, is con¬ 
ducted before the project is summarized in the deliv¬ 
erables. 

2.1.3 High Level Architecture for Simulation 
Interoperability 

Once the necessary tasks are identified and appro¬ 
priate performance measures are identified, the rela¬ 
tive performance of alternative systems architectures 
must be determined. Simulation is a useful tool for 
estimating the effects, task performance, and mission 
effectiveness gained by employing alternative systems 
and strategies in order to accomplish a mission. Un¬ 
fortunately, large-scale simulations that evaluate all 
the necessary metrics are often not available. The 
simulation architecture must be composed from ex¬ 
isting models, possibly built for other purposes. The 
selection of contributing systems should be based on 
the simulated systems, their capabilities, and their 
ability to support the desired metrics. 

High level architecture (HLA) is a series of standards 
developed to support re-usability and interoperabil¬ 
ity between simulation systems. Within the con¬ 
text of this study, I WARS was developed to model 
the dismounted squad-level fight. Both OneSAF 
and COMBAT XXI were developed to model the com¬ 
bined arms fight. Re-usability of and interoperabil¬ 
ity among these systems enable the components of 
one model to be used by other models. In a fed¬ 
erated case, I WARS does not have to independently 
develop combined arms representations, and OneSAF 


and COMBAT XXI do not have to develop high res¬ 
olution dismounted representations. At a basic level, 
in order to be HLA compliant, a federation (group of 
inter-operating models) and its federates (individual 
models in the federation) must comply with ten HLA 
rules (IEEE-SA Standards Board, 2000). The feder¬ 
ates interact via a run-time interface (RT1)(Board, 
2000b) using object models specified in accordance 
with the HLA object model template (OMT)(Board, 
2000a). Because HLA supports time management via 
the RTI, it is a good choice for federations developed 
for large run sets and analysis. 

2.1.4 FEDEP and SEDEP Processes 

HLA standards documents are technically oriented. 
They ensure that, when the w r ork of federation de¬ 
velopment is done, assuming all parties have followed 
the HLA rules, the simulations will interoperate tech¬ 
nically. While this technical interoperability is a nec¬ 
essary condition for a working federation, it does not 
guarantee that the federation will sufficiently por¬ 
tray the simulated domain so that the analysis ques¬ 
tion can be answered. The Simulation Interoperabil¬ 
ity Standards Organization (SISO) recognized this 
problem and developed the HLA Federation Devel¬ 
opment and Execution Process (FEDEP), to address 
it (IEEE Computer Society, 2003). This process is a 
systems engineering approach which provides a top- 
down view r of the federation. It superimposes a pro¬ 
cess and management plan to ensure that the devel¬ 
oped federation is not only technically correct, but 
also meets the objectives for which the federation was 
developed in the first place. The Euclid RI P 11.33 
description of the Synthetic Environment Develop¬ 
ment and Exploitation Process (SEDEP) is a similar 
process, because the FEDEP was used as a guideline 
wdien the SEDEP w r as developed. The necessity to 
build a strong conceptual model before going into the 
technical details is emphasized in both approaches. 

• The SEDEP starts with an explicit User Needs 
Analyses, that is not supported by the FEDEP. 
The following steps are w r ell aligned, as the 
SEDEP understands itself as an enhanced 


l) 



PEO Soldier Simulation Road Map V - The MATREX Federation 


FEDEP. One of the enhancements is the sup¬ 
port of a common repository for all produced 
artifacts. 

• The development process starts with refinements 
of the user requirements that lead to opera¬ 
tionally driven federation system requirements 
for the SEDEP. On the FEDEP side, defining 
the federation objectives and developing a con¬ 
ceptual model for the federation are the counter¬ 
parts. 

• Based on this operational understanding, the 
federation is designed, implemented, integrated, 
and tested in both process models. In both mod¬ 
els. the selection of federates is based on the op¬ 
erational requirements. 

• Finally, the federation is operated, whic h means 
that the federation is executed and respective 
results are prepared. The SEDEP explicitly 
ends the process with performing an evaluation, 
which is partially integrated into the execution 
phase of the FEDEP. 


Both process models clearly show the primary impor¬ 
tance of operational requirements. Both make techni¬ 
cal recommendations, but the implementation details 
are left to the model developers. Additional guid¬ 
ance is needed to ensure that the technical integra¬ 
tion agrees conceptually with the operational view¬ 
point from which the federation requirements were 
developed. 


2.1.5 Levels of Interoperability 

At the core of PEO Soldier’s integration challenge 
is achieving a level of interoperability that goes be¬ 
yond simply ensuring that the models can share data 
and interac tions. The modeled entit ies represent real- 
world people or systems, and the details of the model 
must be sufficient to capture the relevant aspects of 
PEO Soldier’s decision problems. Building federa¬ 
tions under these conditions requires more than a 
simple technical understanding of how simulations 
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Fig. 2; Levels of interoperability. 


exchange data. It requires a common shared con¬ 
ceptual understanding of the simulation environment. 
entities in the models, and exchanges between them. 
It is very difficult to gain this by simply looking at 
source code and conforming to technical standards. 
Levels of interoperability slic'd some light on this chal¬ 
lenge (Tolk et ah, 2006). These levels, shown in Fig¬ 
ure 2, arc 1 arranged in increasing levels of abstrac¬ 
tion. For example, technical interoperability, on the' 
bottom level, is a very specific set of protocols that 
clearly define the standards. Conceptual interoper¬ 
ability, on the highest level, is a loosely defined by 
shared concept that provides context and common 
organizational uses for the models. 

For composable models, the development team must 
have this shared conceptual model prior to detailed 
engineering of the federation. The FEDEP process 
includes this federation conceptual model as a prod¬ 
uct of step 2. but it does not prescribe useful tools 
or processes for developing and distributing this con¬ 
ceptual model. Fortunately, the software engineering 
community has defined a framework to support this 
level of interoperability - Model Driven Architectures. 


2.1.6 Model Driven Architectures 

The Object Management Group’s Model Driven Ar¬ 
chitecture (MDA) is an open standard that enables 


6 



















2 SYSTEMS ENGINEERING PROCESS FOR THE DEVELOPMENT OF FEDERATED 

SIMULATIONS FROM OPERATIONAL REQUIREMENTS 


Level of 

Interoperability 

Applicable tool 

Conceptual 

Interoperability 

DoD Architecture Framework 
artifacts 

Military Mission to Means 
Framework 

Platform Independent Models of 

the Model Driven Architecture 

Dynamic 

Interoperability 

Ontology for Services 

UML artifacts 

DEVS 

Pragmatic 

Interoperability 

Taxonomies 

Ontology 

UML artifacts, in particular 
sequence diagrams 

DEVS 

Semantic 

Interoperability 

Common reference models, such 
as C2IEDM 

Dictionaries 

Glossaries 

Protocol Data Units 
Real-time-Platform Reference 

Federation Object Model 

Syntactic 

Interoperability 

XML 

HLA Object Model Template 
Interface Description Language 

Technical 

Interoperability 

Network and connectivity 
standards, such as HTTP, 

TCP/IP, UDP/IP, etc 


Tab. 2: Applicable tools for each level of conceptual 
interoperability. 


an organization to specify their domain expertise in 
a modeling language that is independent of the tech¬ 
nology used to implement that logic (Object Manage¬ 
ment Group, 2007). This specification achieves the 
technical goal of abstracting the domain logic away 
from the technical implementation details. For a sim¬ 
ulation model, this supports validation of the model 
by domain experts to enable composability. 

The underlying idea is to separate business and aj>- 
plication logic from underlying technology. To en¬ 
able this, MDA defines artifacts based on the Unified 
Modeling Language (UML) to describe a hierarchy of 
models that cope with the various challenges on dif¬ 
ferent levels. Guidelines for the use of MDA establish 
three different modeling viewpoints (Object Manage¬ 
ment Group, 2003a), and these can be interpreted for 
the simulation domain. 

• The highest level of abstraction is the Computer 
Independent Models (CIM). This is a conceptual 
model that identifies the concepts and processes 
important on the business level. This is easily 
mappable to the missions and means identified 
on the operational level. The main artifacts are 
use cases. 

• The Platform Independent Models (P1M) cap¬ 
ture concepts and processes in software engineer¬ 
ing artifacts of class and object hierarchies, ac¬ 
tivities, sequences, and other means showing the 
roles of each component. PIM are very close to 
conceptual models that already use vignette and 
scenario elements motivating the various possi¬ 
ble actions and their sequencing. 

• If this conceptual model is mapped to a concrete 
platform and implementing language, middle¬ 
ware to be used, etc., the result is a Platform 
Specific Model (PSM). In the optimal case, the 
PSM can be used to produce code, as all infor¬ 
mation needed is available. 

It should be pointed out that the models in the dif¬ 
ferent layers are not developed independently from 
each other. Every use case of the CIM must be rep¬ 
resented in form of sequenced actions engaging the 
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roles as concepts in the P1M. The conceptual ideas of 
the P1M must be mapped to implementing entities, 
their capabilities ami associations, and supporting in¬ 
terfaces on the PSM level. In theory, this is supported 
by the use of defining patterns. If the supporting mid¬ 
dleware has an equivalent alternative, this approach 
allows to switch between representing PSM without 
having to change the P1M. In other words: A fed¬ 
eration can be implemented using both middleware 
approaches alternatively. In the WSzS business world, 
some M&S middleware and integration providers are 
utilizing this idea to support the migration between 
equivalent or at least sufficiently close implemen¬ 
tations, such as supporting the Runtime Infrastruc¬ 
ture interfaces defined in 1EEE1516 as well as the 
alternative defined in version 1.3 NG (DoD). 

MDA has the additional advantage of standard¬ 
ized meta-models. The Meta-Object Facility 
(MOF)(Object Management Group. 2002) and XML 
Metadata Interchange (XMl)(Object Management 
Group, 2003b) declare abstractions for the represen¬ 
tation and exchange of models. These features of 
MDA. if applied for modeling and simulation, allow 
simulation system developers to take advantage of the 
numerous modeling and development tools that are 
available in the commercial and open source commu¬ 
nity based on these standards. 

hi order to support both composabihty and agility 
with respect to technical architectures, it seems that 
a formal modeling system for the simulation domain 
should have the following characteristics: 

• It should allow different levels of abstraction, 
such as the C1M-P1M-PSM paradigm, so that 
domain experts can understand and validate the 
model without having to understand computer 
programming and information exchange details. 

• The platform specific model should be ex¬ 
ecutable to enforce a formal structure, but 
it should not require any unnecessary over¬ 
specification related to the technical implemen¬ 
tation. 

• The model should be able to be described us¬ 
ing open standards so that simulation developers 


can take advantage of available tools that have 
evolved in the business community. 

2.1.7 MATREX 

In order to support greater interoperability between 
research and engineering models, the Army's Re¬ 
search. Development, and Engineering Command 
(RDECOM) established a program called the Mod¬ 
eling Architecture for Technology. Research, and Ex¬ 
perimentation (MATREX)(Hurt et al., 2006). MA¬ 
TREX is an implementation of a unified Army federa¬ 
tion to support distributed engineering-level analysis 
within a greater force-on-force environment. At the 
core of this architecture, MATREX provides a run¬ 
time interface (R11), a FOM, and a middleware inde¬ 
pendent capability that allows simulation developers 
to move with agility from different implementations 
of HLA or Test and Training Enabling Architecture 
(TENA). 

These capabilities are enabled by a set of compo¬ 
nents and tools. Key components include battle com¬ 
mand management services which implement feder¬ 
ation services for communications, situation aware¬ 
ness. and command and control. 1 lie Protocore tool 
is a simulation architecture development environment 
that allows federation developers to design a FOM 
and automatically generate source code for partici¬ 
pating simulations that interact with that FOM in 
a middleware independent fashion. This capability 
is based on a transformation from a P1M specifica¬ 
tion, the FOM. to a PSM specification, such as HLA 
1.3. In this sense, MATllEX is a realization of MDA 
in support of federated simulation. The Automated 
Test Case capability allows federation developers to 
use an executable modeling interface to define the 
specifications for test cast's that can be automatically 
generated and used to verify simulation implemen¬ 
tations. Additional infrastructure support including 
initialization, data collection, and analysis are pack¬ 
aged within MATREX. 

In this section, we identified that the MMF and 
ME 1L support the operational analysis of what the 
relevant tasks are when a system needs to be evalu- 
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ated. The result is a description of tasks in the con¬ 
text of vignettes or scenarios with applicable metrics. 
Operational requirements should also drive techni¬ 
cal selection and integration. The NATO Code of 
Best Practice as w r ell as the modeling and simulation 
standards FEDEP and SEDEP show which steps are 
needed to set up and execute a federation. Separat¬ 
ing business logic and platform specification leading 
to a hierarchy of models allows the MDA to facilitate 
the migration between equivalent or closely related 
technical solutions. The MATREX program is a re¬ 
alization of these capabilities within the Army. In 
the next section, we will document a systems engi¬ 
neering process that integrates these ideas enabling 
the seamless management of federation development 
for system evaluation from the operational analysis 
to the technical details of middleware selection and 
interface design. 

2.2 The Systems Engineering Process 

The systems engineering process proposed in this re¬ 
port was motivated by the need to support project 
management with a consistent view of PEO Soldier 
challenges in compliance with relevant processes as 
described in the previous section: 

• The essential tasks to be used for the evaluation 
should be identified to support the selection or 
development of relevant vignettes or scenarios. 

• Simulation systems should be selected based on 
their ability to support the evaluation of these 
tasks. The simulated system capability should 
be the driver for the decision. 

• The process should be applicable to evaluate al¬ 
ternatives for supporting simulation components 
and enable the project manager to make in¬ 
formed decisions. 

• The federation of these simulation systems 
should be supported utilizing the best middle¬ 
ware available for the task. This decision should 
be driven by the functionality of the middleware 
and its necessity in the federation development 
process. 


• The integration of systems and middleware 
should be supported to the maximal extent. The 
decisions of model integrators should be reduced 
to a minimum. This avoids ambiguity of inter¬ 
pretations. Existing solutions should be reused 
as much as possible. 

2.2.1 Identifying Essential Tasks 

In evaluations, operations and training, time and re¬ 
sources are always limited It is necessary to concen¬ 
trate the efforts on the essential tasks. For military 
operations, task lists are a way to support the deci¬ 
sion makers in making the appropriate selection. If 
for example, the effect of a soldier radio is to be eval¬ 
uated, then those tasks which make use of the radio 
must be included in the task list. Soldier communi¬ 
cations tasks are an obvious example. In addition, 
command and control tasks which make use of in¬ 
formation provided via radio communications must 
be analyzed as w r ell. The result is a list of tasks in 
which the systems under evaluation play significant 
roles. This list is represented in form of use cases that 
identify the action performer, the action target, and 
the action itself. An example of a use case diagram 
supporting this effort is shown in Figure 3. This use 
case list can be supported by storyboards and orga¬ 
nizational diagrams of the actors. These elements of 
the CIM are represented using UML. This CIM is the 
result of the first phase. 

2.2.2 Setting the Tasks into Context: Building 
Scenarios, Vignettes, and Metrics 

In the second phase, the actions of the use cases are 
combined to vignettes and scenarios. This allows def¬ 
inition of metrics for each of the tasks in the con¬ 
text of the operational environment. Initially, these 
products are in commonly understood language and 
graphics suitable for the domain to be simulated hi 
the case of the PEO Soldier simulation, An opera¬ 
tional scenario was defined as shown in Figure 4. 

The next step is to begin to transfer the operationally 
oriented descriptions into a computational context. 
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Fig. 3: Use case diagram for soldier scenario. 
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PEO Soldier Simulation Road Map 
HLA Integration Scenrio 

Situation Based on tolelbgencs from a local source. a US squad engaged m counter nsuryency operation* has planned a raid to capture an 
insurgent laadar n the town of Shugart-Gorton Multiple source* of rteligence have confirmed the location of the leader at 
Additionally (hay have reported that his cell members have stationed themselves on rooftops withm the town to identify potential 
Coalition forces and provide early warning to their leader They etso have mortar support The Citizens of Shogart-Gordon have fled the 
village and It is primarily used as an insurgent planning and training center 


Mission 1/1/A/1-5CAV conduct! raid at 011S00MAY08 at 31 1057N 9t 1193W m order to capture local insurgent leader and deny the use of 
Shugart-Gordon as a training sanctuary 

Execution The purpose of this operator « to capture the local insurgent leader in order to gam further intelligence about insurgent operations 
At Ihe and of the operation, we would like to have the nsurgent leader alive and m Coalition custody with no Coalition casualties 
Because the dtizans of Shugert-Gorton have fled the area coasters! damage * of Httte concern 1st squad will conduct the raid with 
direct support from the mortar section They will conduct the reid m three phases, mounted movement dismounted movement and 
clearing the objective During the operation, one fire team will provide overwatch while a second fire team enters the objective building 
to capture the insurgent leader and dear it of enemy fighters Mortar fires wii be used to help dear rooftops of enemy fightars 


Execution Matrix 

Unit 

Phaaa 1 • Mounted 

Movement 

Phase II Dismounted 
Movement 

Phase III Clearing the 
Objective 

Phase IV - Egress 

A Fire Teem 

Mounted in leed vehicle 

Move to Dismounted SBF 
and provide overwatch to 

B TM s movement 

From Dismounted SBF 
provide overwetcb to B 

TM * actons on Objective 
Lift fires when B TM 
begin* breech of door 

Provide overwelch to B 

TM s agrass then 
remount lead veNde 

B Fire Team 

Mounted in trail vehicle 

Move along Dismounted 
Route to position near 
objective 

Breach objective to 
capture insurgent leader 
and dear enemy fighter* 

Egress along dismounted 
route and remount traH 
vehdle 

HMMWV Section 

Move along RT Blue and 
drop teams at Mounted 

SBF 

Provide overwatch from 
Mounted SBF 

Provide overwatch from 
Mounted SBF 

Upon mounting soldiers 
egress etong RT Blue 

Mortar* 

Priority of fire* to 1 *1 

Squad 

Priority of fires to 1st 

Squad 

Pnonty of fires to 1 st 

Squad 

Pnonty of fires to 1 st 

Squad 



Phase II - Dismounted Movement 




At the atari of thta phase blue soldiers 
dismount and control n passed from 
OrteSAF to I WARS Under (WARS 
control, both fire teams move to assigned 
positions During this phase Fire Team A 
occupies support by fire From this 
position, they call for Are against red 
forces on the roof, uung their mortars 


Key 


Soldier Pass Control —> Soldier 

Mortars * CaM tor Fire Soldier 

Mortars Indirect Firs —► Soldier 


A Fire Team moves to 
Dismounted SBF. B Fire 
Team moves along 
Dismounted Route to 
Stack Point in order to 
clear building 


mm 




Fig 4: PEO Soldier simulation scenario. 
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Fig 5: Activity diagram depicting direct fire engage¬ 
ment tasks. 

The resulting hierarchies are captured in UML, but 
they have been proven to support the communica¬ 
tion with military experts as well. Figure 5 shows 
an activity model capturing the overarching tasks of 
the PEC) Soldier simulation scenario. All tasks can 
now be described with metrics. Accuracy and resolu¬ 
tion are decided based on military expertise, not on 
technical constraints. The result of this phase is a 
description of the scenarios or vignettes that should 
bo used to evaluate the aspects of the system un¬ 
der test. An easy bookkeeping chock can make sure 
that all use-cases of phase 1 are considered in at least 
one vignette. Also, each role must be mapped to 
an object. If a complete ML)A approach is used for 
the support, all objects are converted into elements 
of the common warehouse met a- model (CWM), de¬ 
scribed by the Meta Object Facilities (MOF). This 
possibility, however, was not applied in the underly¬ 
ing project so far. 


2.2.3 Identifying applicable Simulation Services 

Up until this point, only operational requirements 
were used to define what should be used to evalu¬ 
ate a system. In this phase, the simulated systems 
and capabilities are used to identify applicable simu¬ 
lation systems. The requirement is that models must 
present their abilities in form of a P1M. The P1M de¬ 
fines a model's ability to model systems, capabilities, 
and activities. Concepts, properties, and processes 
need to be made transparent. The advantage of us¬ 
ing UML artifacts is that it is possible to make the 
system transparent while protecting the intellectual 
property of technical details behind the implementa¬ 
tion. These PIMs look very similar to the artifacts 
produced in the last phase. 

Standardization across the armed forces will support 
alignment. In particular, organizations should name 
the same objects and processes identically and consis¬ 
tently, using these definitions to tag data describing 
the represented concepts, properties, and processes. 
Standards like the Military Scenario Definition Lan¬ 
guage (MSDL) and the Coalition Battle Management 
Language (C-BML) support potential solutions to 
this challenge. A common data administration of 
M&S and command and control would he helpful as 
well. 

The result of this mapping process is the identific a¬ 
tion of simulation systems required to model each 
component activity in within the' defined military 
context. These systems must also produce the re¬ 
quired data for mission, task, and effects assessment. 
This process supports the following objectives: 

• Minimize the number of supporting simulation 
systems that represent the scenario 

• Minimize the costs of obtaining the simulation 
systems and supporting data 

• Maximize the use of simulation system under 
governance of the project manager 

• Maximize the acceptance of systems 
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Fig 6: P1M representation of PEO Soldier scenario 
with simulation system shown as swimlanes, 
selected to model tasks. 

Figure 6 shows a PIM representation of the PEO Sol¬ 
dier scenario with simulation systems identified to 
model each of the represented tasks. 

2.2.4 Preparing the Federation 

The result of the last phase can most easily be visual¬ 
ized as a PIM with swimlanes. Each object and each 
activity is aligned with the simulation system infor¬ 
mation that can be used to represent it. Some objects 
and activities represent general concepts, such as sol¬ 
diers and tanks, and they are likely to be found in 
many systems. Other features are very special, such 
as waveforms for special communications, and only a 
few simulation system will provide them. 

The PIM with swimlanes can now be used to sup¬ 
port the decisions on which system should represent 
which objects and activities. This decision is trig¬ 
gered by the objectives enumerated at the end of the 


last subsection. The optimum for the analysis would 
be to maximize the coverage of operational require¬ 
ments, but other constraints - such as time, funding 
available, or security concerns of model providers 
can limit the feasible solution. However, no matter 
what motivates the ultimate selection of models, it 
is very likely that at least two models are selected 
that need to be federated to provide all necessary ca¬ 
pability. Only in rare cases, everything is provided 
by one model, and no federation support is needed. 
Whenever an activity connects two objects hosted in 
different systems, or whenever properties needed to 
support the activities or the identified metrics for one 
object are provided by different systems, a federation 
is needed to handle the interactions and updates. 

The patterns supported by MDA to move from PIM 
to PSM support integration with applicable middle¬ 
ware. Alternative middleware solutions can be sup¬ 
ported, such as mapping to package data units of the 
IEEE1278 Distributed Interactive Simulation (DIS), 
or objects and related methods within the object 
model used by TENA. The use of web services is an¬ 
other option. Furthermore, mixed strategies can be 
supported, such as using the Extensive Markup Lan¬ 
guage (XML) file based MSDL for initialization, the 
HLA based update of attributes and sending of in¬ 
teractions for simulation based information exchange 
during runtime, and web service based information 
exchange with C2 systems based on C-BML. 

Another more conservative application is the defini¬ 
tion of stubs for information exchange requirements 
to be enhanced by the implementing simulation sys¬ 
tems. If a future simulation shall replace one of the 
current systems, the interface does not change. In 
fact, the initial simulation can test the federation 
and perform preliminary analysis. When the replace¬ 
ment simulation is implemented, it federates using 
the same interfaces. The MDA pattern identifies ex¬ 
actly what elements and procedures, methods, and 
callbacks need to be supported. 

To support the PEO Soldier scenario for this project, 
the following steps v/ere performed. 

1. PEO Soldier decided that the following essen¬ 
tial tasks will be sufficient for a first evaluation: 
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transport in a HMMWV, direct fire engagement 
with insurgents on the top of a roof, clearing a 
house in search of at least one enemy inside, indi¬ 
rect and direct fire from hostile forces that will 
result in a call for fire to a supporting mortar 
unit. 

2. The resulting scenario activities are captured 
in Figure 5. The resulting PIM could be used 
to identify two models that if used in conjunc¬ 
tion provide the desired capability and met¬ 
rics for PEO Soldier: One Semi-Automated 
Forces (OneSAF) and Infantry Warrior Simu¬ 
lation (IWARS). While OneSAF provides the 
frame for the scenario, IWARS provides the 
high-resolution models to evaluate the effects of 
soldier equipment such as body armor and night 
vision goggles. 

3. The scenario activities were separated into One¬ 
SAF activities and IWARS activities. Wherever 
a crossover shows up, information needs to be 
exchanged. Figure 6 shows the activities side by 
side. This step is the equivalent of the PIM for 
federated simulation development. 

4. PEO Soldier decided to base the on-line cou¬ 
pling of OneSAF and IWARS on IILA as the 
interoperability standard. They used the MA¬ 
TREX FOM for the information exchange model 
and MATREX tools for federation development. 
Therefore, the information exchange require¬ 
ments resulting from the PIM mapping in step 
3 had to be mapped to RTI calls and the use 
of classes and interactions with attributes and 
parameters defined in the FOM. For example, 
the “call-for-fire" activity had to be mapped to 
a “call for fire* interaction as defined in the MA¬ 
TREX FOM. The relevant object classes and in¬ 
teractions used to support the PEO Soldier sce¬ 
nario are shown in Figures 7 and 8. 

5. Based on the activities identified in step 3 and 
the classes identified in step 4, sequence dia¬ 
grams were developed that broke down the func¬ 
tional activities in the simulation into specific 
actions and communications for the federation 


using data elements from the MATREX FOM 
Together, steps 4 and 5 of this process represent 
a detailed technical architecture for the federa¬ 
tion that can be implemented using a specific 
interoperability infrastructure - HLA using the 
MATREX FOM and RTI. These represent the 
PSM for federated simulation. Figure's 9 and 10 
show sequence diagrams representing platform 
specific implementation of direct and indirect fire* 
engagements from firers in one model engaging 
targets in another model. 
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Fig. 7 PEO Soldier FOM class diagram 
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Fig. 8 PEG Soldier FOM interaction diagram. 
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Fig. 9: Sequence diagram for IWARS direct fire at a OneSAF entity. 
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Fig 10: Sequence diagram for OneSAF mortar fire at I WARS target. 
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3 RESULTS 


3 Results 

Using the architecture described in the previous sec¬ 
tion, the development team came together for an in¬ 
tegration exercise to test the capabilities of the feder¬ 
ation. The scenario was designed not necessarily for 
doctrinal correctness, but to serve as a good test for 
the models. It needed to be simple to execute, but it 
also needed to provide the right level of interactions 
between the two models. Figure 11 shows the initial 
scenario screens for both OneSAF and IWARS. The 
scenario called for a squad of infantry to mount in 
two HMMWV’s in order to move into a small town 
to raid a house. 

As the HMMWV’s approach the town, enemy look¬ 
outs are spotted on the roof of a home, and the 
friendly forces call for fire. The enemy forces and 
dismounted observer are represented in IWARS, and 
the mortars are represented in OneSAF. Once the call 
for fire is executed, the rounds impact in and around 
the building, incapacitating the enemy lookouts as 
shown in Figure 3. These interactions, represented 
in the sequence diagram of Figure 10, test the ability 
of IWARS to pass call for fire information to IWARS 
and the ability of OneSAF to engage forces repre¬ 
sented in IWARS with indirect fire. 

Once the enemy lookouts on the roof are cleared, the 
HMMWV’s stop at a dismount point, and the mem¬ 
bers of the squad dismount the vehicles in order to 
infiltrate on foot to the raid target. As the squad 
dismounts, their control is passed from OneSAF to 
IWARS, shown in Figure 13. 

The dismount squad breaks into two teams, and one 
moves into a support by fire position while the other 
moves toward the raid objective. The HMMWV’s 
remain in an overwatch position blocking one of the 
roads out of the town. At this time, two armed insur¬ 
gents come to the rooftop of the raid objective and 
fire at the approaching squad. They are spotted and 
engaged by the HMMWV’s, as shown in Figure 14. 
This sequence of events demonstrates the ability of 
the insurgents, controlled by IWARS, to have a di¬ 
rect fire engagement with the HMMWV’s, controlled 
by OneSAF. The sequence diagram in Figure 9 rep¬ 


resents information exchanges for these interactions. 

As the insurgents on the rooftop are incapacitated, 
the raid team moves to the objective and clears the 
house of remaining insurgents, as shown in Figure 15. 
This activity takes place only in IWARS. 

The scenario concludes, and relevant performance 
measures can be collected from IWARS results, One¬ 
SAF results, or from data collected from the network 
during the federated run. 
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Fig. 11: Scenario startup screenshots for OneSAF (left) and I WARS (right) 



Fig. 12- 


Enemy lookouts on a rooftop are engaged by mortars 
dismounted enemy forces are set'll in I WARS (right). 


in OneSAF' (left), and the effects on the 
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Fig. 13: As the HMMWV’s stop in OneSAF (left), the raid squad dismounts, and their control is passed to 
I WARS (right). 





Fig 14: HMMWV’s in OneSAF (left), fire at insurgents controlled by I WARS (right). 
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Fig 15: OneSAF (left) shows the results of the room clearing activity which takes place in I WARS (right). 
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4 PLANNING FOR ACADEMIC YEAR 2008-2009 WORK 


4 Planning for Academic Year 
2008-2009 Work 


This year’s effort gives a capability for movements, 
target acquisitions, and firing effects to be exchanged 
between the models. While this progress is signifi¬ 
cant, much more work needs to be done before this 
federation is ready for analysis of complex soldier 
equipment such as the Ground Soldier System, a dis¬ 
mounted command and control capability. Soldier 
communications, situation awareness, and command 
and control decisions must be represented. In addi¬ 
tion, the federation must be able to support auto¬ 
matic start and stop, time management, and data 
collection for analysis. Finally, even thought the in¬ 
dividual models have been verified and validated, the 
federation itself must be verified, validated, and ac¬ 
credited for use in an Army study. 


4.1 Simulation Architecture 


In order to support these modeling tasks, an updated 
federation architecture must be developed. A high- 
level view of this architecture is shown in Figure 16. 
Within this architecture, IWARS is expected to per¬ 
form high resolution simulation of soldiers on the bat¬ 
tlefield. Specific components from the MATREX ar¬ 


chitecture will provide battle command capabilities. 
MATREX provides a group of federates in the Battle 
Command Management Services (BCMS). The Mes¬ 
sage Transceiver Service (MTS) provides an interface 
to a communications models such as the Communi¬ 
cations Effects Server. In the upcoming year, this 
project will attempt to identify an appropriate com¬ 
munications effects federate to model soldier com¬ 
munications. This federate will by linked with the 
MATREX architecture via the MTS, which provides 
HLA interfaces for communications messages. In ad¬ 
dition the Situation Awareness Dissemination Service 
(SANDS) will correlate and fuse situation awareness 
for soldier leaders on the battlefield at the team, 
squad, and platoon level. The Soldier C2 Model will 
be developed at West Point in order to read situa¬ 
tion awareness data from SANDS and order subor¬ 
dinates to change mission parameters based on this 
awareness. This Soldier C2 model will be aware of 
the friendly situation, mission, enemy situation, and 
terrain. Its decision algorithms will provide better 
decisions when presented with more complete and 
more accurate situation awareness information that 
would be presented via soldier communications sys¬ 
tems such as the Land Warrior System or Ground 
Soldier System. OneSAF or COMBAT XXI will simu¬ 
late the effects of mounted forces or higher-level units 
on the battlefield with which soldiers operate. 

4.2 Tasks 

From the planned architecture shown in Figure 16. 
a list of development tasks was prepared for each 
model development team to carry forward into the 
upcoming development year (See Annex B). These 
tasks were staffed to each development team for re¬ 
view and costing. Based on the feedback, PEG Sol¬ 
dier provided sufficient funds to each team in order to 
continue development in accordance with the planned 
architecture, using the assigned tasks. These tasks 
were integrated into an overall project plan for aca¬ 
demic year 2008-2009, shown in Annex C. 
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Fig 16 Planned simulation architecture for assessment of command and control systems. 
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Nomenclature 


BOMS Battle Command Management Services 

C-BML Coalition Battle Management Language 

C2 Command and Control 

COMBAT XXI Combined-Arms Analysis Tool for the 
21st Century 

D1S Distributed Interactive Simulation 

FEI)EP Federation Development and Execution 

Process 

HLA High Level Architecture 

1WARS Infantry Warrior Simulation 

MATREX Modeling Architecture for Technology 
Research and Experimentation 

MATREX Modeling Architecture for Technology, 
Research, and Experimentation 

MDA Model Driven Architectures 

MMF Military Missions and Means Framework 

MOF Meta-Object Facility 

\1S1)L Military Scenario Definition Language 

MTS Message Transciever Service 

NATO North Atlantic Treaty Organization 

OMT Object Model Template 

OneSAF One Semi-Automated Forces 

ORCEN Operations Research Center of Excellence 

PEO Program Executive Office 

RDECOM Research Development and Engineering 
Command 

RT1 Run rime Interface 
RT1 Runtime Interface 

SANDS Situation Awareness Dissemination Service 


SEDEP Synthetic Environment Development and 
Exploitation Process 

S1SO Simulation Interoperability Standards Orga- 
nizat ion 

SMART Simulation and Modeling for Acquisition 
Requirements and Training 

STMS Soldier Tactical Mission System 

TENA Test and Training Enabling Architecture 

UML Unified Modeling Language 

USMA United States Military Academy 

VMASC Virginia Modeling Analysis and Simulation 
Center 

XM1 XML Metadata Interchange 
XML Extensible Markup Language 
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ANNEX A - Development Tasks for Academic Year 2007-2008 


Tab. 3. COMBAT XXI Modeling Tasks 


Title 

Description 

Remarks 

Real Time 

Interoperability 

Develop hard-linkages between COMBATXXI and 

IWARS 

Current Work Program will not allow us to begin 
hard-linkages prior to Dec 07 Objective is to 
model platoon MOUT objective in IWARS and 
then transfer to COMBATXXI for follow on. 

Combat XXI ERC 

Integrate ERC into COMBATXXI. 

ERC proponent must provide ERC with a Java 
interface for this to be accomplished. 

Attend TEM's 

Attend Technical Exchange Meetings 

Until Dec 07, meetings should occur at 
TRAC-WSMR when possible, or by VTC. 

SWA 100 Scenario 

Provide SWA 100 COMBATXXI Scenario. 

Provided when complete and tested 

Combat XXI MSDL 

Schema 

Implement MSDL schema into scenario 
input/output into COMBATXXI 

Current Work Program will not allow us to begin 
integration of MSDL schema prior to Dec 

07 Spring SIM publishes draft MSDL in 

March. Final schema published at Fall SIM. 

Academic year 2008-2008 COMBAT xxl modeling tasks 


Tab. 4: [WARS Modeling Tasks 


Title 

Description 

Remarks 

Thermal Weapons 
Sight Improvements 

Develop, in conjunction with AMSAA, the 
trade-off performance parameters, associated with 
10%, 25%, 50% and 100% capability 
improvements (resolution) for the Thermal 

Weapon Site; and create data tables to integrate 
these inputs into the IWARS model to support 
analysis within the context of a Southwest Asia 
operational use case 

Most likely needs detail classified information from 
PM-SWAR We would also want to get some the 
data from NVESD studies pertaining to 
classification of hand-held items 

IWARS MSDL 

Schema 

Implement MSDL schema into scenario 
input/output into Infantry Warrior Simulation 

Spring SIM publishes draft MSDL in March Final 
schema published at Fall SIM. 

Academic year 2008-2008 IWARS modeling tasks 
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Tab. 4: IWARS Modeling Tasks 


Title 

Description 

Remarks 

IWARS Thermal 

Weapons Sight 

Scenario 

Create IWARS scenario to analyze the effects of 
Thermal Weapon Site within high density urban 
environment in a desert environment, typical of 
operations within Southwest Asia, during both day 
and limited visibility scenario. 

Operational use case would be that of a SE Asia 
desert location. Objective end state would be to 
have a level of compatibility with, or take a slice of 
the TRAC HRS 100 or 110. An urban canyon 
that is roughly 300 meters in depth to test rifle 
and optic effects to this distance may be part of 

the use case. To ensure a common terrain 

representation with the other simulations for the 
area of interest, we would be dependent upon 
others to provide the specific terrain database(s). 

Entity level sensory 

and behavior 

algorithms for TWS 

Develop the entity level simulation sensory and 
behavior algorithms associated with enhanced 
Thermal Weapon Site capabilities within the 
context of a Southwest Asia operational use case 

Related to IWARS 01 and IWARS 03 

Thermal Weapons 
Sight Analysis 

Conduct an analysis using the products from steps 

1, 3, & 4. Provide results to PEO Soldier and 

USMA 

There are numerous steps in this process, many of 
which are called out in a previously provided 

narrative Would want numerous interactions 

with PEO-Soldier and USMA during execution 

Real time 

interoperability 

Continue to address necessary linkage elements in 
conjunction with the OneSAF and COMBATXXI 
groups, working towards a hard linkage with each 
COMBAT XXI and OneSAF individually 

Linkage elements will either focus on elements 
compatible with TRAC WSMR scenarios being 
worked during this period, near-term analysis needs 
of PEO Soldier or on representing FFW and GSS 

within the context of FCS to facilitate simulation 
based analysis, training, experimentation or 
testing. Specific elements supporting hard linkage 
have been previously identified. The major issues 

that would have to be addressed are different with 

OneSAF and CXXI, i.e. method of exchanging 
data Form of delivery will need to be discussed 

Academic year 2008-2008 IWARS modeling tasks 
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Tab. 4: I WARS Modeling Tasks 


Title 

Description 

Remarks 

IWARS 

Communications 

Work with the OneSAF and COMBATXXI (Lead) 
groups in addressing the analytical needs 

associated with communications and their 

effects. There are two main issues, the first being 
the representation of ‘Communications 

Equipment’ and the second includes the 
representations of actions that can be taken based 
upon having the information from the 
communications, i.e "Netted Effects. Call for 

Fire”. 31DEC07 The solutions to integrating these 
capabilities in the models are different. The first 
requires that parameters associated with the 
communications equipment have an impact upon 

the success of the communication. The second 

requires that behaviors are developed and utilized 
that allow the computer entities to take actions 
(fires) based upon the information passed in the 
communication 

The solutions to integrating these capabilities in 
the models are different. The first requires that 
parameters associated with the communications 
equipment have an impact upon the success of the 
communication The second requires that 
behaviors are developed and utilized that allow the 
computer entities to take actions (fires) based 
upon the information passed in the 

communication 

Long-term Issues 

"Work with PEO Soldier and other agencies, as 
required and as opportunities arise to address 
long-term issues of interest to the PEO A number 
of specific areas have been explicitly identified. 

- Analytical needs associated with Soldier borne 
power and energy 

- Analytical needs associated with the 'Direct Fire 
Weapons' area of endeavor 

- Benefits of an "Integrated Vision / Aim Point 
System" on lethality. - Analytical needs associated 
with the "Blue Soldier Tracking Alerts” area of 
endeavor 

- Analytical needs associated with the Interceptor 
Body Armor, integrated head, neck, and face 
protection, and Advanced Combat Helmet areas of 
endeavor. 

- The need to work to obtain a minimum-spanning 
set of operational use cases that will support 
materiel development, analysis and 
experimentation 

- The set-up, conduct, and reduction of 
experiments that support the collection of data 
needed for analysis 

- The set-up, conduct, and reduction of analysis 
pertaining to issues of importance to the PEO 
Soldier. 


Academic year 2008-2008 IWARS modeling tasks 
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Tab. 5: OneSAF Modeling Tasks 


Title 

Description 

Remarks 

OneSAF Casualty 
Modeling 

Development of capabilities/affects for advanced 
body armor and the Thermal Weapon Site and 
integration of the Integrated Casualty Estimation 
Model (ICEM). This includes conceptual modeling, 
KA/KE, model implementation, integration, and 

test 


Command and 

Control Items 

Work with the IWARS and COMBATXXI groups 
in addressing the needs and benefits associated 
with the Netted Effects: Call for Fire," 

"Integrated Vision/Aim Point System," "Blue 

Soldier Tracking Alerts," "Direct Fire Weapons," 
and "Communications Equipment” area of 

endeavors. 


OneSAF MSDL 

Implement MSDL schema into scenario 
input/output into OneSAF 

Spring SIM publishes draft MSDL in March Final 
schema published at Fall SIM. 

ERC 

As the primary effort for this year, serve as the 
"Lead" to activities pertaining to facilitating the 
integration of the OneSAF Environmental Runtime 
Component (ERC) into Combat XXI and 

IWARS. Collaborate with the other two modeling 
groups to ensure that efforts are aligned and 
mutually supportive to enable ERC utilization of 

the COMBAT XXI scenario SWA 100 

Terrain decks may be classified, and if necessary, 
require a SIPR Line 

Academic year 2008 2008 OneSAF modeling tasks 
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ANNEX B - Planned Development Tasks for Academic Year 2008-2009 
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Task 

Assigned To 

Description 

Remarks 

Continued HLA Federation 

Development 

Combat XXI 

Work ith other modeling teams to 
continue HLA development to ard a 
more robust representation of 
communications command and 

control lethalit and protection 

Specific tasks include 

Build MATPE* communications support 

Build MATPE* fires aichitecture support 

Build MAT PE* situation a. are ness support 

Build behavioral responsesto MAT RE* Soldier 

C 2 interactions. 

Assess federation analysis 
capabilities 

Combat **.1 

Use a snail scenario to assess the 

federation's capability to assess the 
operational alue of different soldier 
architectures includingthe current 
soldier system Land tt ; arrior and 

Ground Soldier S> stem 

Specific tasks include 

Update interface to Protocore 4 1 

Update support for EPC andMSDl 2 5 

Support automata fe delation start stop 
Supporttime management 

Support entit o ■ nerstup transfei 

Document SOM in OMT 

De ■ elop data c Tiectron capabilities t support 

anal sis. 

Communications Modeling 

Combat **l 

i 

Develop a capability for IWARS to run 
as a stand-al ne communications 

effectsmodel 

This communications model must , ork in a 

MAT RE* aichitecture by integrating ith the 

MAT RE* Message Transceiver Service iMTS}. It 
.• ill recei .e messages from MTS and use the 
Brigade and Belov.' Propagation and Protocol 
i,B2P2!i model to determine hethei message 
passedfrom sender to receivei 

Develop PEO Soldier 

Scenarios 

Combat **l 

Fromcurrentl appro edTPADOC 

scenarios ork v. ith USMA and PEO to 

extract small scale anal>sis ignettes 

from , rthin those scenarios. These 
ignettes should address recurring PEO 
Soldier analysis questions. 

Deliverables ill be MSDL le presentations of 
these scenariosfoi use h> all of the sub rdmate 

models Assignme nt :f this task is intended to 
leverage the soldier analysis expertise of TPAC- 
VVSMR 

Soldier ModellngTeam 

Combat <*1 

Participate in t o annual soldier 
modeling team conferencesto discuss 

common concerns ith respectto 
d<.elopmentprocesses behaviors 
algorithms and data 



Fig. 17: COMBA'I xx, tasks for academic year 2(K)S-2(K)f). 













Task 

AsslgnedTo 

Description 

Remarks 

Continued HL A 

IWARS 

Work with other modeling teams to 
continue HLAdevelopment toward a 
more robust representation of 

communications, command and 

control lethality, and protection. 

Specific tasks include 

Build MATREX communications support 

Build MATREX fires architecture support 

Build MATREX situation awareness support 

Build behavioral responses to MATREX Soldier 

C2 interactions 

Integrated Casualty 

Estimation Model 

IWARS 

Develop a methodology and data 
requirementsforthe use of ICEM 

re suits in combat simulations. 

AMSAA cooperation is required for this task 
Run-time issues prevent real-time linkage with 

ICEM 

Rules of Engagement 

IWARS 

Develop representations and soldier 
behaviorsthat capture the effects of 

IFF systems and rules of engagement 

in combat simulations. 

The fidelity of these representations depends 
on progress in the underlyingscience from 

acrossthe R&D community 

1 

j 

Assessfe deration 

analysis capabilities 

IWARS 

Use a small scenario to assess the 
federation’scapability to assess the 

operational value of different soldier 
architectureslncludingthe current 
soldier system Land Warrior and 

Ground Soldie r System 

Specifictasks include 

Update interface to Protocore *4 1 

Update support for ERC andMSDL 2 5 

Support automatic federation start,'stop 
Supporttime management 

Support entity ownership transfer 

Document SOM in OMT 

Develop data collection capabilities to support 
analysis 

ImproveSTA processfor 
soldier sensors 

IWARS 

Improve representation of soldier 
sensorsandthe search andtarget 
acquisition process within combat 

simulations 

Where appropriate implement existing 
methodologies in IWARS 


Fig. 18. IWARS development tasks for academic year 2008-2009 
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Task 


Assigned To Description 


Remarks 


Continued HLA 

Federation Development 

OneSAF 

Work ith other modeling teams to 
continue HLA deselopment t< ard a 
more robust representation of 
communications command and 

control lethalits and protection. 

$pe cific tasks include 

Build MATPEX communications support 

Build MATPEX fires architecture support 

Build MATPEX situation ac areness support 

Build be haMoral response sto MATPE> Soldier 

C2 interactions 

! 

Asse ssfe deration 

analysis capabilities 

i 

OneSAF 

Use a small scenario to assess the 

fedeiation'scapahilitv to assess the 
operational alue of different soldier 
architectures including the curre nt 
soldi< i system Land A arrior and 

GroundSoldier S.stem 

Specific tasks include 

Update interface to Piotocored 1 

Update support foi EPC and MSDl 2 S 

Support automatic federation stait st i 

Support time management 

Supportentity o nership transfer 

Document SOM in OMT 

De e lop data collection capabilities to supp it 
analysis, 

Soldier Mode ling Team 

OneSAF 

Participate intAO annual soldier 
modeling team conferencesto 

discuss common concerns ith 
respeetto de elopment processes 
behav ioi s algorithms and data 


Assess Federation 

Analysis Capabilities 

PEO Soldier 

Use a small scenario to assess the 

federation'scapability to assess the 
operational alue of different soldiei 
architectw es including the cuirent 
soldier system Land'A arrior and 

GroundSoldier Syste m 

Specific tasks include detailed desci iptions of 
different soldier as a system 

architectures Provide analysis questions that 

currentl ansv ei PEO Soldiei decision 
challenge 5 V vith respeetto these architectures 

Map soldier capability 
gapsto modeling 
requirements 

PEO Soldier 

PEO Soldier should identif and 
pi loritize the soldier capability gaps 
the v are addressing The, ill the n 
ork ith the Simulation Poad Map 
team to map those gaps to 

simulation re quite me nts so that 

simulation resources can be dnected 

at the issues of concei nfoi the PEO 



Fig. 19 OneSAF and PEO soldier tasks for academic veal* 2008-2009 
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Task 

AssfgnedTo 

Description 

Remarks 

AssessFederation 

Anaiysis Capabilities 

USMA 

Use a small scenario to assess the 

federation's cap ability to assess the 
operational value of different soldier 
architecturesincludmgthe current 
soldier system Land Warrior and 

Ground Soldier System 

Specific tasks include orchestrating input data 
development across the models conducting 
the analysis runs collecting and analyzing 
output data answering the study question 
and providing feedback about model 

development priorities that would enhance 
the analysis capabilities of the federation 

Command and Control 

Mode line 

USMA 

Build an ability for reactive command 

and control into the federation 

These behaviors must be friendly 

enemy and terraina/ are 

First effort will be to identify soldier C2 
behaviorsat individual fire team squad and 

platoon level Then develop C2 interactions to 
be used in the FOM to pass these behaviors 

into the models Once each model has built 

internal responses to these C2 behaviors 
develop C2federates that pass ordersto 

soldie r e ntitie s base d on update d C2 
information about friendly forces enemy 

force s mission and terrain 

MDAfor Federation 
Development 

VMASC 

Continue to assess the applicability 

of Model Driven Architecture sto the 

federation development process 

Fortlusyear place particular emphasis on the 
further development of the 

MATPEX/PROTOTCOPE environment in order 

to use a systems engineeringapproach to 
move from requirements to system selection 

to orchestration and e *ecution. 

Battle Management 
Language for Soldier C2 

VMASC 

Supportdevelopment of soldier C2 
architecture with Battle 

Management Language iBMll 
re presentations of soldier C2 tasks 

Support includes data definition for BMl 
structure sand prototype implementation of 

command and control federates that assess 

the current situation and issue ordersto 

soldiersusing BML 

Assessfe deration 
analysis capabilities 

VMASC 

Use a small scenario to assess the 

federation scapability to assess the 

operational value of different soldier 
architecturesincludmgthe current 
soldier system land Warrior and 
Ground Soldier System 

Specific VMASC task will be to focus cm the 
federation'shandling of data for analysis How 
doesthe analyst configure the federation to 
collectthe appropriate data to supportthe 
analysis questions given the different data 

collection instruments on the federation and 

within the individual models 

Federation development 
engineering 

management plan 

VMASC 

Develop an engineering 
management plan to supportthe 
federation development tasks 
plannedfor academic year 2008- 
2009 Support execution of thart plan 

with assessments of on-time and 
performance criteria during 

execution 

Delivery ofthe plan would take place tov ard 
the end of the summer to support planmngfor 

next year s effort 


Fig. 20: USMA and VMASC tasks for academic year 2008-2000 
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